权力上收责任下放是取乱之道

最近这二十多年时间做了不少项目，也接触过大量的用户。二十多年前，IT管理方面相对比较粗犷，到用户现场时候也没太多流程和管控措施，早期甚至把自己的笔记本电脑连到用户的网络上就开展工作了。自己带的各种工具用起来很方便。这种管理模式漏洞很多，不利于企业IT的安全管控，因此很快堡垒机、运维专区等纷纷建立。再去用户现场干活的时候只能用客户提供的运维终端了。

经过十多年的发展，一些大企业的IT管理都完善了不少，从安全的角度上看，确实很有必要。不过我手头的一些不错的工具和脚本都没法用了，做事情麻烦了一些。虽然对我们这种做第三方服务的人来说不够友好，我还是比较认可企业在安全管控上的这些升级的 。真正让我觉得有些不解的是，在提升安全管控的同时，很多企业IT运维管理方面的官气大了不少。

今年有个用户的系统出现比较严重的性能问题，心急火燎的让我派人去现场帮忙看看。我们的工程师到了现场三天没能摸到系统，都在走各种流程。还没等流程走完，系统真的出大问题了，我们那哥们还在酒店等待，突然晚上被叫到现场。这回啥流程都不用走了，因为系统已经无法使用了。于是直接上系统操作，十分钟帮用户搞定了问题。无独有偶，在另外一个优化项目里，我们的一个专家到了现场，因为他没有参加过安规考试，因此没有资格连线系统操作，因此他只能坐在一边请一个不太懂数据库的哥们帮他敲指令查数据用于分析问题，工作效率之低，令人发指。后来实在受不了了，就希望让现场的人放宽一下限制，通融一下，让他直接操作几下。现场的人也十分委屈，说这地方到处都是摄像头，如果期间出了什么问题，那么这个不合规的操作将会让他背负十分严重的责任，甚至可能会因此丢了饭碗。

事后和客户的DBA聊天，谈到这个问题，他也十分无奈。他说IT部门这些年在不断提升管理，不过总结其主要特点，最主要的特点是权力上收，责任下放。权力上收是指一些决策权都上收了，原来上系统做诊断、监控、分析、优化都是一线的标准权利，他这个层面就可以决策了，现在在他们这里，这些权利都上收到部门级别，甚至更高的级别了。这些操作都必须审批才可以做的，如果没有经过审批，都属于违规，一旦出了问题，责任相当大。按理说权力上收了，职责应该也同时上收，系统出问题就应该由上级领导承担最大的责任了。不过事实上并非如此，现在职责反而是下放了，出问题后要出来承担责任都是没啥权力的一线部门。    

加强管理后责任划分十分明确，而且绩效和收入、升职等直接挂钩，因此一线人员不得不考虑一些自保的手段。以往大家都是主动运维，平时也经常会自己对系统的运行状态、性能问题做一些分析，并主动提出一些优化方案。在现在的这种管理模式下，DBA只能通过那些简单的监控系统和APM去运维数据库，到数据库上去采集数据与分析问题都必须提交操作申请，一旦正好你在操作时系统有了点问题，那么你想澄清是很困难的，因此主动运维和主动找死没啥区别。

上面有政策，下面也必然有对策。目前他们平时很少直接登录数据库做运维操作，只是通过监控系统看看数据库的状态与日志告警，或者通过APM系统定期导出一批慢SQL，作为成果上报到运维系统，交由开发商去整改优化。每年系统都会购买原厂的巡检服务，原厂巡检服务中主要提及的也是慢SQL和补丁问题。慢SQL往往只是APM采集的一个子集，补丁要不要打是上级部门决定的事情，他们只需要把报告交上去就行了。

运行模式这么转变一下，上级领导感觉管理都闭环了，上报的问题似乎也少了一些。正好赶上这几年刚刚升级了系统，更换了硬件，因此除了应用问题以外，似乎其他问题也少了不少。应用优化是个常态化工作，每年也有相应的经费在支撑，业务部门有啥问题都是研发在应对，IT运营似乎运行良好。

看似风平浪静的海面下其实暗流涌动，这种模式下，管理制度虽然严格了，不太容易出现管理问题了，但是一线运维只剩下了一张皮了，系统中存在的一些亚健康状态大多被掩盖住了，一线的运维分析能力也大大退化了，一些水平较高的DBA纷纷离职，目前在一线的DBA都是一些经验呢不足的新手。再加上系统隐藏的小问题没有被及时发现，积累下来时间长了，就会积累出大问题，某个时间点上集中爆发出来，就是大问题。事实上，这个客户这两年出现过几次比较大的生产故障，我也帮助分析过。事实上那几次故障都是一些不难分析的问题触发的，按照几年前他们的运维能力，应该都是能够在一个小时内解决问题的，不过那几次故障都持续了半天以上。    

权力上收，责任下放现在在很多企业里都已经成为惯例，从管理角度看，似乎严谨了许多。甚至在一些不太懂IT技术的高层领导眼里，这是很好的管理模式，不过在以技术为核心的运维领域，这其实不是一种高明的管理手段，而是取乱之道。